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THE  INTELLIGENT  PROGRAM  EDITOR 

A  Knowledge  Based  Syetea  for  Supporting  Prograa  and  Documentation  Maintenance 

Daniel  G.  Shapiro 
Brian  P.  McCune 


Advanced  Information  A  Decision  Systems 
201  San  Antonio  Circle,  Suite  286 
Mountain  View,  CA  94040 


ABSTRACT 

This  paper  presents  work  in  progress  towards  a 
program  development  and  maintenance  aid  called  the 
Intelligent  Program  Editor  (IPE),  which  applies 
artificial  intelligence  techniques  to  the  task  of 
manipulating  and  analysing  programs.  The  IPE  is  a 
knowledge  based  tool :  it  gains  its  power  by  expli¬ 
citly  representing  textual,  syntactic,  and  many  of 
the  semantic  (meaning  related)  and  pragmatic 
(application  oriented)  structures  in  programs.  To 
demonstrate  this  approach,  we  implemented  a  subset 
of  this  knowledge  base,  and  a  search  mechanism 
called  the  Progrem  Reference  Language  (PRL),  which 
is  able  to  locate  portions  of  programs  based  on  a 
description  provided  by  a  user.  This  work  is  an 
applied  research  effort.  It  was  motivated  by 
issues  discovered  during  a  study  of  software 
maintenance  problems  in  the  Air  Force,  and  is 
intended  to  be  moved  into  application  within  7 
years. 


1.  INTRODUCTION 


The  effort  and  expense  involved  in  software 
maintenance  have  bean  recognised  as  major  limita¬ 
tions  on  the  capabilities  of  current  software  sys¬ 
tems.  The  difficulties  arise  for  several  reasons: 
first,  although  hardware  costs  have  decreased, 
software  expenses  have  skyrocketed  owing  to  the 
higher  cost  of  professional  programmers.  Second, 
as  software  projects  have  become  mere  and  more 
ambitious,  the  technical  difficulty  of  making 
changes  to  the  resulting  programs  has  increased 
dramatically.  As  an  illustration  of  this  fact,  the 
maintenance  costs  for  large  systems  typically  sur¬ 
pass  the  funds  required  for  their  initial  develop- 
nent;  ae  a  case  in  point,  the  Defense  Department 
now  speeds  more  than  3  billion  dollars  per  year  on 
software  maintenance.  These  problems  are  addressed 
in  pert  by  the  creation  of  standardised  structured 
programming  languages  such  as  Ada,  but  in  our  opin¬ 
ion  they  will  only  be  solved  by  the  results  of  new 
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research  into  automated  programsing  support  sys¬ 
tems.  He  expect  that  many  such  tools  will  rely  on 
the  application  of  artificial  intelligence  tech¬ 
niques. 

To  gain  better  insight  into  the  specific  prob¬ 
lems  of  software  maintenance,  AI6DS  performed  a 
study  which  analysed  software  maintenance  problems 
in  the  Air  Force*.  The  study  concluded  that  the 
process  of  comprehending  the  form  and  function  of 
existing  software  (i.e. ,  what  it  does  and  how  it 
does  it)  is  the  most  crucial  step  in  the  swinte- 
nance  process.  A  number  of  tools  which  can  affect 
that  problem  within  the  medium  term  (3  to  7  years) 
were  defined. 

This  "comprehension  problem”  is  revealed  in 
many  ways.  To  begin  with,  most  progranming  instal¬ 
lations  have  a  high  turnover  rate  of  personnel  and 
have  trouble  finding  qualified  replacements.  As  a 
result,  the  maintenance  personnel  are  often  unfami¬ 
liar  with  the  program  that  is  being  maintained.  At 
the  same  time,  documentation  is  often  unavailable, 
or  of  poor  quality  when  it  is  available.  This 
increases  the  difficulty  of  comprehending  a  given 
program.  It  is  not  easy  to  understand  a  program  by 
directly  reading  the  code  because  of  the  quantity 
of  detail  involved  and  also  because  coding  stan¬ 
dards  are  poorly  enforced  end  rarely  agreed  upon. 
Finally,  the  process  of  isolating  bugs,  designing 
solutions,  and  determining  the  ramifications  of 
changes  is  difficult  in  the  presence  of  an  incom¬ 
plete  understanding  of  the  program's  organisation. 
The  relative  difficulty  of  this  task  is  affected  by 
the  tools  available  to  the  prograamer. 

The  software  maintenance  study  identified  a 
collection  of  tools  designed  to  alleviate  these 
problems,  ell  of  which  rely  on  a  sophisticated 
understanding  of  the  structure  of  programs.  In 
effect,  they  operate  by  transferring  some  of  the 
expertise  currently  in  the  minds  of  progrsamers 
into  a  machine  usable  form  that  can  be  ahared. 
Three  of  the  smet  relevant  tool  ideas  are  suaaMr- 
ited  below. 

The  Intellixent  Fronrsm  Editor  (1FE)  is  a 
knowledge-based  tool  for  supporting  the  development 
sod  maintenance  of  software.  It  embodies  a  deep 
understanding  of  the  structure  of  programs  and  of 
the  manipulations  which  progrsasMrs  typically  apply 
to  code.  It  can  provide  access  to  a  variety  of 
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intelligent  tool#,  e.g.,  the  Documentation  Assis¬ 
tant  described  below. 

The  Documentation  ttiMal  ie  a  system  that 
helpe  organise,  obtain,  aa in tain  and  acceaa  nan; 
different  forme  of  documentation,  ranging  from  line 
by  line  conmenta  to  deeign  principle!  and  applica¬ 
tion  oriented  raquiraiente  that  underly  the  struc¬ 
ture  of  code  as  s  whole.  The  Documentation  Assis¬ 
tant  it  intended  to  provide  knowledge  which  other 
systems  (such  as  the  IPS)  can  employ. 

The  Ptotrammina  Hanater  assists  the  prograamer 
by  systematically  applying  administrative  and 
technical  policiee.  It  enforces  soma  procedures 
(e.g.',  testing  of  code  before  installation),  sug¬ 
gests  others  (e.g.,  notifying  a  user  group  of  a 
change),  and  automatically  performs  some  actions  on 
its  own.  the  Programming  Manager  is  also  intended 
as  a  form  of  Documentation  Assistant  for  expressing 
heuristic  knowledge  about  code,  for  example,  that 
bugs  in  module  A  often  cause  run-time  errors  in 
module  B. 

At  the  currant  time,  AIAD8  is  actively  working 
on  all  of  the  tools  described  above.  The  remainder 
of  this  paper  focuses  on  a  description  of  the  1PB 
and  of  the  knowledge  it  will  contain.  We  conclude 
with  a  scenario  demonstrating  an  actual  implementa¬ 
tion  of  a  portion  of  the  IPE's  knowledge  base  used 
in  the  context  of  a  program  search. 

2.  THE  IMTILLICtWr  PB0C1AM  EDITOR 

The  Intelligent  Program  Editor  (IPS)  is  a  tool 
now  being  developed  to  support  software  development 
and  maintenance  in  a  sophiaticatad  way*.  The  sye- 
tem  gains  its  power  through  the  use  of  aa  explicit 
model  of  the  programing  proceee,  and  a  databaea 
called  the  Extended  Program  Modal  (the  EPM),  which 
represents  the  functional  structure  of  code.  The 
1PE  uses  this  knowledge  to  support  the  design  and 
manipulation  of  programs  as  semantic  objects;  this 
should  be  contrasted  with  the  text  string  viewpoint 
that  most  editors  provide.  For  example,  the  IPE 
will  be  able  to  automatically  fill  in  syntactic 
forms,  prompt  the  user  during  the  completion  of 
programming  cliches,  and  monitor  a  program  for 
semantic  consistency  while  it  is  being  modified. 
We  expect  the  IPE  to  model  the  type  of  the  user's 
programming  activity,  and  to  help  choose  or  invoke 
appropriate  tools. 

The  payoff  of  the  IPE  may  be  extrmely  large 
in  terms  of  enhanced  programmer  productivity  and 
increased  reliability  of  code.  Productivity  will 
be  improved  because  the  system's  high  level  vocabu¬ 
lary  and  manipulation  methods  will  allow  mainte¬ 
nance  requests  to  be  completed  faster.  Eeliability 
will  be  enhanced  because  the  IPS  will  automatically 
catch  certain  kinde  of  semantic  errors  that  were 
formerly  paesed  into  delivered  code.  In  addition, 
the  IPE  will  have  a  large  impact  on  the  area  of 
program  comprehension;  since  it  maintains  a 
knowledge  base  that  documents  code  from  a  variety 
of  perapectivae,  it  provides  a  forum  for  transfer¬ 
ring  expertise  that  was  formerly  lost  as  program¬ 
mers  moved  on  to  different  teaks  and  jobs.  If 
these  effects  cumulatively  produce  as  little  as  a 
one  percent  effect  on  the  maintenance  process  in 


the  U.S.,  the  savings  will  be  measured  in  the  tens 
of  millions  of  dollars  annually. 

Pigure  1  contains  a  block  diagram  of  the  IPE. 
The  aystm  is  composed  of  three  major  parts :  the 
Exteniifcd  Program  Model,  which  provides  knowledge  of 
program  structures  and  how  to  access  them;  a  Pro¬ 
gramming  Context  Model,  which  lets  the  system 
understand  soma  of  the  user's  intent  at  he  accesses 
or  modifies  code;  and  a  collection  of  semantic 
analysis  and  manipulation  tools  that  provide  the 
progranmer  with  a  mere  powerful  vocabulary  for 
manipulating  programs,  above  the  level  of  character 
by  character,  or  line  by  line  changes.  The  IPE 
alto  contains  a  user  interface  and  a  programing 
executive  which  coordinate  the  facilities  of  the 
tyttm  and  present  them  to  the  user.  The  user 
interface  will  use  multiple  windows  and  allow  com¬ 
mands  to  be  typed  or  selected  from  menus.  See 
reference  2  for  details. 


Figure  Is  The  Intelligent  Program  Editor  (IPE) 


2.1  THE  PKOG BAMMING  CONTEXT  MODEL 

The  Progranming  Context  Model  is  a  knowledge 
bsse  that  identifies  the  sequence  of  activities 
that  are  typically  involved  in  the  process  of 
developing  and  maintaining  code.  This  information 
supports  the  IPE  in  a  variety  of  ways,  but  in  par¬ 
ticular  it  allows  the  systmt  to  guide  the  program¬ 
mer  through  the  coding  sequence  and  to  remind  him 
of  actions  which  he  has  not  performed.  For  exam¬ 
ple,  the  Programing  Context  Model  lists  program 
creation,  debugging,  modification  and  exploration 
as  major  contexts,  and  refines  program  creation 
into  functional  definition,  algorithm  definition, 
data  structure  selection  and  coding.  Since  the 
coding  process  is  further  defined  to  include  docu- 
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■to tat  lea,  tht  m  con  invoke  tht  Dociasantat  ion 
Assistant  tool  and  prompt  the  utor  to  provide 
specific  types  of  formatted  information  vfato  each 
new  nodule  ia  defined. 

The  contest  aodol  alao  gives  the  IPE  a  way  to 
invoke  ita  own  facilitioa  at  appropriate  tiaaa. 
For  exsnple,  if  the  naar  ia  in  the  procoaa  of 
defining  an  algorithm,  then  the  ayaten  will 
autonatically  anarch  tha  EPM's  databaae  of  typical 
progrsnming  patterna  to  ana  if  a  relevant  template 
can  be  applied.  (It  ahould  be  nan tinned  that  the 
IPE  will  not  enforce  a  particular  sequence  of  cod¬ 
ing  activitiee.  Our  philosophy  is  to  allow  the 
prograaaaer  to  frooly  jump  between  programing  con¬ 
tests  as  he  desires.) 

2.2  HANIPULAT10R  AMD  A  MALTS  IS  TOO.  I 

The  IPS's  aaaipulation  and  analysis  tools 
directly  employ  the  knowledge  sources  ia  the  DM. 
These  tools  are  responsible  for  making  additions 
and  deletions  to  the  EPM's  store  of  information, 
and  for  using  its  data  to  run  semantic  checks  on 
the  user's  program  aa  it  ia  formed.  (Tha  EFM 
itself  also  does  lower-level  checking  automatically 
to  ensure  the  internal  consistency  and  well- 
formedness  of  its  multiple  knowledge  representa¬ 
tions.)  We  have  defined  several  toola  of  this  kind 
that  the  IPE  should  contain.  In  addition  to  the 
Documentation  Assistant  diecusaed  previously,  the 
IPE  will  have  an  advanced  program  manipulation 
facility,  a  semantic  error  detection  tool,  and  a 
style  analysis  capability.  These  are  described  in 
the  following  sections. 


2.2.1  Advanced  Program  Manipulation 

An  intelligent  editor  that  has  a  substantial 
amount  of  knowledge  about  the  semantic  structure  of 
programs  and  about  the  s aunties  of  meaningful 
operations  can  supply  much  better  support  to  the 
prograeaer.  Por  example,  it  is  possible  to  provide 
operations  that  directly  transform  ’Vhile"  loops 
into  "for"  loops,  or  iterations  into  recursions. 
Another  type  of  syntactic  operation  interactively 
constructs  a  subroutine  call  by  prompting  the  user 
for  the  name  and  actual  parameters  of  a  routine. 
This  process  will  ensure  that  the  number  and  type 
of  the  arguments  in  the  calling  statement  agree 
with  the  declarations  in  the  procedure's  implemen¬ 
tation. 

The  IPE  will  also  provide  templates  for  more 
semantic  constructs,  such  aa  the  typicel  program¬ 
ming  patterns  (described  later)  which  are  the 
building  blocks  that  programmers  use  to  implement 
larger  algorithms  ox  routines.  With  this  informa¬ 
tion  in  hand,  the  system  will  be  able  to  guide  the 
user  through  the  implements! ion  of  sophisticated 
routines  by  prompting  for  each  functional  part  of  a 
routine  by  uaing  e  unuonic  word  or  phrase. 


2.2.2  Semantic  Analysis 

The  semantic  analysis  tools  within  the  IPE 
allow  the  system  to  identify  sections  of  code  which 
violate  principles  of  correct  program  construction. 
These  principles  define  “rational  form*  constraints 
which  restrict  the  allowable  composition  of  pro¬ 
grams.  Por  example,  traditionel  type  checking 
operations  for  atrongly  typed  languages  ensure  that 
assignment  statements  are  never  used  between  vari¬ 
ables  that  are  declared  to  be  of  incompatible 
types.  Similarly,  it  ia  not  reasonable  to  use  a 
variable  before  it  is  initialised.  As  s  third 
example,  a  rational  form  constraint  insists  that 
all  sectiona  of  a  program  can  in  fact  be  reached 
through  some  sequence  of  control  steps  (and  yet, 
many  large  programs  often  contain  dead  regions 
which  cannot  be  executed  even  in  principle). 

The  semantic  analysis  tools  perform  these 
kinds  of  operations  by  examining  the  representa¬ 
tions  which  the  SPM  provides.  The  data  which  sup¬ 
ports  these  capabilities  are  described  in  Section 
2.3. 


2.2.3  Style  Analysis 

Some  programing  styles  (patterns  of  program¬ 
ming  language  usage)  are  hard  to  comprehend  and  are 
subject  to  inadvertent  or  diff icult-to-detect 
errors.  Guidelines  of  good  style  include  advice 
about  making  systema  modular,  adding  conments  to 
the  code,  clearly  describing  any  assumptions  made, 
and  minimising  the  use  of  “side-effects",  etc. 

Currant  automated  style  analysis  tools  are 
limited  to  straightforward  syntactic  analysis  of 
code.  Style  analysis  in  the  IPE  will  be  similar  in 
nature  to  the  semantic  analysis  discussed  above, 
except  that  the  rules  will  be  recommendations 
rather  than  roquirasmts.  Sy  making  the  style 
analyser  a  tool  of  the  IPE,  style  analysis  can  be 
done  on  an  incremental  basis,  e.g.,  each  time  a 
module  is  completed.  Tha  user  can  use  all  of  the 
facilities  of  the  IPE  for  altering  code  or  documen¬ 
tation  to  conform  to  the  style  analysis  guidelines. 
When  appropriate,  the  IPE  might  be  able  to  perform 
simple  transformations  to  automatically  correct 
style  violations.  In  addition,  the  user  would  be 
provided  with  the  ability  to  modify  the  style 
rules,  so  that  ones  which  are  not  essential  and 
which  conflict  with  the  user's  preferred  style  can 
be  suppressed. 

In  keeping  with  the  philosophy  of  the  IPE, 
style  rules  can  be  textual  (e.g.,  “loop  bodies 
should  be  indented"),  syntactic  (e.g.,  "don't 
assign  to  loop  variables  inside  e  loop"),  eemaotic 
(“don't  use  expressions  with  side  effects  in 
declarations"),  or  even  application  oriented  in 
nature. 


2.3  ns  EXTEgDED  PEOGIAM  MODEL 

Ths  Extended  Prograa  Model  (EPM)  io  a  ijrita 
for  representing  aad  accessing  progrtas  in  a 
sophisticated  way.  It  acceapliahes  thaaa  tasks  by 
defining  a  vocabulary  for  discussing  programs  which 
uaaa  terao  that  are  much  closer  to  the  oaee  which 
programmers  aatwrally  aaploy.  The  DM  provides 
this  capability  through  ths  use  of  a  knowledge  base 
that  represaats  the  structure  of  prograas  f row  a 
variety  of  views:  froa  low-level  textual,  or  char¬ 
acter  by  character  iaforaatioa,  to  explicit  saa an¬ 
tic  structures  that  docuaeat  the  programer's 
intent  for  a  piece  of  code.  This  iaforaatioa 
correspoada  to  what  we  believe  the  Docuaeatation 
Assistant  aad  the  other  asaipulatioa  aad  analysis 
tools  discussed  earlier  need  to  use.  Thus,  the  STM 
can  fora  the  backbone  for  a  maker  of  systans  which 
exhibit  a  deep  understanding  of  the  organisational 
structure  aad  aeaaiag  of  code. 

The  BPM  is  constructed  in  terns  of  two  aajor 
subsysteas  (css  Figure  2):  a  database  of  prograa 
structures  (the  FSDt)  and  a  ssarch  and  updating 
component  called  the  Prograa  teference  Language  (or 
PH.),  which  provides  access  to  the  PSDI.  la  addi¬ 
tion,  the  EPM  contains  a  library  of  "rational  fora" 
constraints  that  will  aoaitor  prograa  coaposition 
for  its  ssaantic  content.  As  a  whole,  the  systan 
can  be  thought  of  as  a  database  aanagenant  systan 
for  aaiutsiniug  coda.  It  provides  a  search 
language  for  accessing  its  knowledge,  a  facility 
for  perforaing  updates,  as  well  as  a  set  of  saaan- 
tic  integrity  and  consistency  constraints  for 
aouitoring  the  validity  of  the  data  it  contains. 

EPM 


figure  2.  The  Extended  Prograa  Model 


2.3.1  The  Prograa  Etructuret  Database 

The  EPM's  knowledge  or  database  of  prograa 
structures  (the  PSDE)  is  constructed  ia  terns  of  s 
hierarchy  of  representations  which  reflect  the 


transition  froa  a  syntactic  to  a  acre  intention- 
oriented  analysis  of  cods  (Figure  3).  For  the  pur¬ 
poses  of  the  PEL,  we  are  considering  these 
viewpoints  to  be  abstract  data  types  which  facili¬ 
tate  different  sorts  of  retrieval  operations. 


Figure  3.  A  Hierarchy  of  Prograa  Structures 
in  the  EPM 


The  textual  representation  gives  the  EPM  the 
view  that  aost  text  editors  provide.  It  is  a  low- 
level  approach,  concerned  with  words  and  deliaiters 
as  opposed  to  the  saasntics  of  prograas,  but  it 
allows  for  iaportsnt  textual  search  operations.. 
Siailarly,  the  syntactic  viewpoint  is  provided  by 
some  prototype  text  and  "structure"  editors.  It 
aa bodies  the  rules  of  graaaer  for  particular  pro¬ 
graming  languages.  Ths  syntactic  knowledge  base 
provides  the  EPM  with  a  vocabulary  for  progressing 
constructs  such  as  "for"  loops,  procedures,  and  the 
visible  and  private  designations  ia  Ada  prograas. 

At  the  next  level,  we  have  provided  a  eeg- 
aented  parse  abstraction  which  defines  s  vocabulary 
for  a  prograa  ia  teras  of  its  coaponent  data  and 
control  flow.  to,  for  sxaaple,  iterations  are 
decoa posed  into  a  set  of  roles  which  identify  the 
subfunctions  of  e  loop.  In  the  breakdown  we  are 
using,  loops  contain  generators,  filters,  termina¬ 
tors,  aad  au^estetions3.  Generators  are  segneats 
which  produce  a  sea  senes  of  values.  They  .  *n  be 
further  refined  into  initialisations  and  a  body, 
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which  ia  tha  portion  that  la  executed  an;  tiaaa. 
Filter*  raatrict  that  aaguanca  of  value*.  A  terui- 
aater  ia  like  a  filtar,  aacapt  that  it  haa  tha 
additional  potaatial  to  atop  osacutioo  of  tha  loop. 
Aa  augnaotation  conaiaaaa  waluaa  and  prodwcaa 
xaaulta.  Thate  ara  othar  vocabulary  alaaanta  for 
daacribiag  atraight  liaa  coda. 

Tha  taxonomy  that  haa  baao  diacuaaad  up  until 
thia  poiat  primarily  capturaa  information  about  tha 
fora  of  prograa*  aa  oppoaad  to  thair  aaaaiog.  Tha 
only  a am antic  alaaaata  wa  haw  a  iatroducad  daacribe 
tha  auhatructura  of  built-in  oatitiaa  auch  aa 
loopa.  la  tha  next,  awra  abatract  wiawpoiat,  wa 
coaaidar  prograaa  to  bo  built  of  ohjacta  with 
atarootypod  purpoaaa.  Thaaa  ara  cal lad  typical 
prograaniag  pat  tana  (TFFa).  Kaanplaa  of  TFFa 
iocluda  variahla  iatorchaagoa,  liat  inaartiona,  and 
haah  tahla  ahatractioaa.  Thaaa  abatractioaa  ara 
tha  too  la  aaployad  by  ovary  aapart  progrtwr. 
Rich  haa  dafiaad  a  library  of  auch  TFFa4. 

Tha  remaining  knowladga  baaaa,  i.a.,  intan- 
tioaal  annotation*,  iatoational  aggragataa  and  tar- 
tun  1  docuaantation,  all  provida  aatboda  for  aaaoci- 
atiag  the  iataationa  behind  a  prograa  with  apacific 
faaturaa  of  coda.  Thay  often  capture  pragmatic 
knowladga  relating  to  the  doauin  of  application  of 
the  prograa.  For  example ,  an  intentional  annota¬ 
tion  aight  identify  tha  author,  creation  data,  and 
Modification  hiatoxy  of  a  particular  file,  or 
record  comment*  about  the  goala  and  aaamaptioaa  of 
a  apacific  routine.  Intentional  aggragataa  aaaoci- 
ata  larger  program  fragaanta  with  key  worda  aup- 
plied  by  tha  programmer.  Thay  can  ba  uaad  to  col¬ 
lect  the  TFFa  and  othar  program  faaturaa  that 
implement  a  aingla  purpoae. 

Tha  documentation  knowladga  bate  allowa  tha 
uaer  to  aaeociate  textual  comment*  with  any  of  the 
prograa  faaturaa  already  deacribed.  So,  for  exam¬ 
ple,  ha  can  document  tha  data  flow  in  a  particular 
module  (aaying  why  an  input-output  ralationahip 
occura),  juatify  hia  uae  of  particular  TFFa,  or 
explain  why  particular  ayatactic  faaturaa  ara 
employed.  Thia  knowledge  baaa  taker  advantage  of 
tha  EPM'e  partitioning  of  program  knowladga  to 
claaaify  comment*  in  uaaful  waya.  For  example,  tha 
textual  documentation  knowledge  baaa  ia  aimed  at 
capturing  aoma  of  tha  aamantica  implicitly  aaeoci- 
atad  with  the  textual  coMenta  that  are  normally 
attached  directly  to  coda. 


In  order  to  damonatrate  the  faaaibility  of  tha 
CFM,  wa  implemented  a  portion  of  tho  knowledge  baaa 
deacribed  above,  and  built  a  varaion  of  tha  IFM'a 
aaarch  facility  (tha  PIL)  which  operatea  on  that 
data. 

Tha  PEL  ia  a  tool  for  locating  ragioua  of  pro¬ 
gram  text  baaed  upon  a  daecriptioa  provided  by  tha 
uaer.  Aa  a  aupport  ayatma,  it  prow  idea  programmer* 
with  a  mechaniam  for  iaolatiag  portion*  of  program* 
in  aituation*  where  thay  ara  not  familiar  with  the 


detailed  atructura  of  the  cod*.  Thia  occur*  in  the 
procea*  of  editing  program*  which  ara  too  large  to 
rmmber  explicitly,  in  the  act  of  undaratanding 
cod*  which  haa  rarely  baaa  aaan  before,  or  in  the 
proceea  of  completing  partially  implemented 
deaigna.  In  the  context  of  program  maintanaaee, 
tha  FA  help*  to  alleviate  aom*  of  tho  burden  on 
the  programmer  by  cupplyimg  an  intention-oriented 
vocabulary  for  referencing  cod*. 

The  Program  Reference  Language  Implementation 
(FtLI )  allowa  prograa  aaarch  baaed  on  four  of  the 
rapraaantationa  deacribed  above,  namely  the  tex¬ 
tual,  ayntactic,  aegnantad  para*  and  typical  pro¬ 
gramming  pattern  view*  (Figure  A).  Theae  knowledge 
baae*  are  connected  through  a  "code  region" 
abatraction  that  aaaociatea  prograa  feature*  with 
phyaical  lection*  of  program  text. 


Figure  4.  The  Prograa  Reference 
Language  Implementation 


Tha  FRLI  ha*  a  flat  information  atructure.  It 
repreaent*  each  knowledge  baae  in  term*  of  a  com¬ 
plex  tree  or  graph  atructure  of  from**.  However, 
the  knowledge  baae*  hove  no  direct  link*  between 
on*  another,  although  the  ayatma  can  arbitrarily 
convert  between  viewpoint*  by  uaing  code  region*  a* 
an  intermediary.  The**  eonvaraiona  ara  heuriatic 
procaaae*  ainca  the  aaparat*  rapraaantationa  typi¬ 
cally  do  not  correapond  on  a  one  to  on*  baai*. 

In  tb*  context  of  our  applied  work,  are  have 
alao  raatrictad  the  typaa  of  information  the  FRLI 
contain*.  The  information  ia  ita  databaae  ia 
either  automatically  available  (baaed  on  current 
reaearcb  prototype*),  or  can  ba  reaaonably  obtained 
from  tb*  uaer.  In  aituation*  whir*  the  latter  ia 
necoaaary,  we  aaaum*  that  information  nay  be 
provided  in  aa  incomplete  form.  It  i*  important  to 
not*  that  ovary  tin*  a  piece  of  docuaantation  ia 
added  to  the  ay  a  ten' a  knowladga  bate,  tb*  parfor- 
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nsei  of  tbt  MB.  will  inert  tit.  Tbit  tbould  have 
tht  tfftet  of  encouraging  tbt  addition  of  intona¬ 
tion  by  tba  prograwer ,  which  haa  always  ban  a 
aajor  problem  with  tba  creation  of  documentation. 


3.1  CODE  PAINTING 

From  a  computational  point  of  view,  the  ruin 
problem  involved  with  tbit  multiple  repreantation 
approach  ia  to  define  a  mechanism  that  is  able  to 
compare  intonation  obtained  from  the  differnt 
sources  of  knowledge.  The  IIL1  accomplishes  this 
via  the  code  region  abstraction,  which  functions  as 
a  conmon  language  that  each  of  the  representations 
can  use  to  "communicate". 

Code  regions  support  two  different  approaches 
to  search.  In  the  first  method,  which  we  call 
sequential  filtering,  the  user  makes  a  gross  stab 
at  selecting  a  code  region  by  generating  all  of  the 
elements  which  satisfy  a  fairly  easy  condition.  He 
then  sequentially  restricts  that  act  by  applying 
more  and  more  conditions.  For  example,  to  find 
"the  loop  which  computes  the  sum  of  the  test 
scores",  he  locates  the  set  of  all  loops,  and  then 
restricts  it  to  the  ones  which  involve  teat  scores 
and  summations. 

In  the  second  approach,  tha  user  identifies  a 
collection  of  items,  possibly  from  several  dif¬ 
ferent  knowledge  bases,  and  intersects  them 
together  to  find  the  elements  which  satisfy  all  of 
the  conditions  he  wants  to  impose.  In  this  "code 
painting"  approach,  tha  FEL1  views  each  element  of 
a  knowledge  base  as  a  specification  for  a  region  of 
program  text  (meaning  a  portion  of  the  program 
text);  it  combines  th«  by  essentially  overlaying 
the  corresponding  regions  of  code.  For  example, 
the  user  locates  the  "loop  which  computes  the  etas 
of  the  test  scores"  by  figuratively  coloring  all 
loops  red  end  all  places  that  compute  the  sums  of 
test  scores  yellow.  Any  region  which  cornea  up 
orange  has  all  of  the  properties  that  were  deeirod. 
The  implementation  of  code  painting  is  described  in 
reference  3. 

Code  painting  la  a  deliberately  coarse  affair. 
It  is  designee  to  exploit  the  kind  of  incomplete  or 
even  slightly  inaccurate  information  which  the  EFN 
will  contain,  given  that  much  of  the  data  ia  pro¬ 


vided  by  the  user.  In  many  cases,  code  painting 
may  not  identify  the  exact  section  of  the  program 
which  the  user  desired,  but  ia  the  context  of  an 
interactive  system  with  a  screen  oriented  display, 
close  will  be  good  enough. 


3.2  A  SCENARIO  USING  THE  PEL  I 

The  following  example  shows  how  tha  PEL  I  uses 
the  code  painting  paradigm  to  answer  the  question 
"find  the  initial isatione  of  the  loop  which  com¬ 
putes  tbe  sum  of  the  test  scores",  given  the  Ada 
program  shown  in  Figure  5.  (This  is  a  modified 
version  of  an  actual  transcript  that  is  presented 
in  reference  3.  A  sequential  filtering  scenario  is 
also  provided  there.) 

In  this  example,  the  user  starts  by  identify¬ 
ing  three  sett  of  data,  corresponding  to  the  simmM- 
tion  TPPs,  syntactic  loops,  and  segmented  parte 
frames  involving  the  test  score  array. 

>  (index  'simmatioo  tpp-databate) 

«>  TPPsetl 

>  (index  'loops  syntax-database) 

«>  LOOPsetl: [length  2) 

>  (index  'TEST-S00EE8  segp-database) 

->  SEGsetl : (length  61 

The  program  only  contains  one  TPP,  but  there 
are  two  loops,  and  several  segments  which  relate  to 
the  variable  TEST-SCORES.  It  is  important  to 
notice  that  these  segments  use  the  data  contained 
in  the  variable  TEST-SCORES  but  do  not  necessarily 
reference  it  by  that  name.  For  example,  the 
literal  "A(I)"  in  the  ARSAYSUM  function  accesses 
the  test  score  array.  This  correspondence  is 
available  from  the  data  flow  analysis  within  tbe 
segmented  parse. 

Tbe  user  intersects  these  descriptions  by 
invoking  the  code  painting  paradigm.  The  code¬ 
painting  algorithm  returns  the  largest  region  of 
text  which  can  be  described  in  all  three  ways. 


for  NAXSIZE  in  1..10  loop 
TOTAL  :•  AEEATSUN  (TEST -SCORES ,  NAXSIZE); 
put  (TOTAL); 
end  loop; 


function  AEEATSUN  (A:  in  ARRAY;  R:  in  INTKEt)  return  IVTaGEt  ie 
begin 

SUM:  RIAL:-  0; 
for  X  in  1..N  loop 
SUM;-  SUM  ♦  A(l); 
end  loop; 
return  SOM; 
end  AUATIUM; 


Figure  3.  The  Program  Used  in  the  Scenario 
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>  (overlay-codc-regioa*  Wiltl  LOOPsetl 
SEGeetl) 

->  C0DE-UBI0M1 

—tor  X  in  I..W  loop 
SOM:-  SOM  «  1(1); 
end  loop;** 

In  order  to  eonpute  thie  inf oraat ion ,  .  the 
overlay  function  automatically  convert*  the  input 
aete  into  their  corresponding  region*  of  code.  In 
the  ca*e  of  the  TPP,  the  progxsmmer  had  to  define 
that  napping  at  «on*  tin*.  The  other  tranalation* 
are  available,  but  Muriatic  in  nature. 

At  thi*  point,  the  u*cr  ha*  identified  a  loop 
uhich  eonpute*  the  iin  of  the  ta*t  acore*.  In 
order  to  find  the  initialization*  of  thi*  code,  he 
view*  thi*  region  fron  the  aegnented  par**  perspec¬ 
tive,  and  acana  it  for  **gnant*  of  the  appropriate 
type.  The  tern  ”initialiaationH  ia  a  eegnanted 
par**  keyword. 

>  (Filter  (Seg*-Uithin  OOOE-tSGlOBl) 

'(Sag-Type  "initialisation")) 

->  SEGaet 2: (length  2] 

The  FELI  convert*  OOOE-UCIOR1  to  a  act  of 
■egnented  par**  frane*  (a  heuristic  proce**),  and 
the  function  8*g*-Within  enumerate*  the  subsegments 
it  contain*.  The  *y*tan  identifies  two  initialisa¬ 
tion*  a*  a  result.  The  user  print*  than  by  con¬ 
verting  than  to  the  textual  view. 

>  (show I  SBGs*t2) 

->  for  I  in  **1..M**  loop 

->  **S0M:  SEAL.—  0;** 

The  answer*  correspond  to  the  initialisation* 
of  the  iteration  variable  "1",  and  the  accimlatioa 
variable,  "SUM".  The  PH. I  retrieve*  the  second 
initialisation,  even  though  it  i*  lexically  outside 
of  the  •  valuation  loop  itself.  It  ia  identified 
fron  the  segnented  pare*  analyaie,  which  associate* 
a  loop  and  it*  initialisations  no  natter  how  far 
apart  they  night  have  been  in  the  original  codv 


requests  of  the  kind  denonstrated  in  thi*  paper 
(based  on  a  single  user  query).  Vhen  the**  exten¬ 
sion*  are  couplets,  the  PEL  will  define  a  nor*  for- 
wal  reference  language. 

The  task  of  building  a  prototype  for  the  ZPE 
involve*  a  nunber  of  issue*  including  the  incremen¬ 
tal  nodification  of  knowledge  base*,  and  the 
recognition  of  user  intention*  in  code.  In  order 
to  solve  the**  problem*  in  the  context  of  our 
applied  research,  we  expect  to  rely  heavily  on 
nethods  for  eliciting  information  J row  the  user, 
and  to  focus  on  taaplata-oriented  techniques  for 
manipulating  program*. 
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4.  CUKKEMT  8TAT08  AWD  POmUfltt 


AIADS  i*  now  developing  a  prototype  version  of 
the  Intelligent  Program  Editor,  which  is  intended 
to  demonetrat*  the  efficacy  of  our  knowledge  based 
approach  to  the  design  of  programming  support 
tool*.  The  prototype  will  embody  a  portion  of  all 
of  the  facilities  that  have  bean  described:  the 
EPM,  the  PEL,  a  collection  of  manipulation  and 
analysis  tool*  and  the  Program  Context  Model.  The 
IPS  is  currently  targeted  for  language*  such  as  Ada 
and  CMS-2.  It  will  run  initially  on  a  Symbolic* 
3600,  a  fast,  personal  LISP  conputar  that  feature* 
a  high-resolution  bit-map  display. 

In  term*  of  (pacific  modification*,  w*  expect 
to  augment  the  EPM'*  knowledge  base  to  include  more 
pragmatic  information  (e.g. ,  the  relation  between 
requirement*  and  program  atructurea),  and  w*  intend 
to  extend  the  PEL  to  the  point  where  it  will  be 
able  to  automatically  plan  and  carry  out  search 


